1. Field of the Invention
The present invention relates to information processing and systems therefor, and, more particularly, to techniques for managing objects in a such systems (e.g., techniques that offer multiple levels of undo and support for delegation of updates on main-memory resident objects accessible by concurrent transactions).
2. Description of the Related Art
Mechanism for automatically noting updates to object and/or memory in information processing systems have been devised in the context of persistent programming languages (PPLs) and Object-Oriented Database Management Systems (ODBMS). These mechanisms are geared towards gathering the new values of the persistent objects updated by a program so as to propagate them atomically to durable storage upon instruction by the program to do so (via a commit or checkpoint operation). Noting mechanisms typically work in two steps. First, during normal execution, modified objects are “noted” using some auxiliary data structure (a bit in the object header, or a card table, or a remembered set). Then, upon a commit or checkpoint request, the updates to the noted objects are reported atomically onto durable storage, typically by recording the updates onto a log (so as to minimize commit or checkpoint latency), then by propagating opportunistically the updates to the copies of the objects in secondary storage. Depending on the strategy chosen and on the noting mechanisms, the noted objects may be logged in their entirety, or their updated part is precisely identified by comparing their copy in main-memory with the one obtained from secondary storage. Although these mechanisms have been designed for fine-grained logging of updates in programming systems that combine programming languages with transactional capabilities, they are generally inadequate to support undo operations. This is because undo operations require taking an image of at least the updated part before the update takes place (whereas noting mechanisms only identify those objects that have been modified). PPL and ODBMS support undo but only to persistent objects. Thus, the mechanisms employed are unfit for systems without a backing store. Additionally, these noting mechanisms were designed for architecture where each transaction accesses persistent objects via a private buffer, and are therefore not viable for systems that support the execution of multiple concurrent transactions that directly access the same set of main-memory resident objects (such as systems that allow maintaining a single shared buffer of persistent objects directly accessible and modifiable by all transactions). Lastly, these noting mechanisms do not address multiple levels of undo or delegation of updates.
Main-memory resident database systems employ undo techniques that may be fit for use on volatile objects. Some implementations employ undo log records that are maintained in volatile main memory. In addition, some implementations also maintain a per-transaction private log of undo records to avoid synchronization when generating an undo log record. However, conventional techniques do not support features desired or required by advanced transaction models, e.g., multiple level of undo and delegation of updates.
Some implementations of disk-oriented traditional database systems include undo mechanisms with support for multiple level of undo and delegation. However, these mechanisms are too heavyweight and the assumptions they make are inappropriate for the runtime of a modern programming language. In particular, the mechanisms they employ assume that updated objects are stored at a fixed location for the duration of the transaction (e.g., the same disk page). Such an assumption conflicts with the automated heap management adopted by modern programming languages which may cause objects to relocate in memory at any time. To ensure that updates are rolled back in exactly the reverse order they were performed, each log record is assigned a unique, monotonically increasing, log sequence number (LSN). A LSN identifies a location in the log, and is used to mark the page(s) that contains the updates recorded in the corresponding log record. The use of LSN is specific to the write-ahead logging techniques. Accordingly, conventional approaches do not offer, and consequently there is a need for, multiple levels of undo, perhaps together with support for delegation of updates, for example, on a main-memory resident shared heap of objects accessible by concurrent transactions.